1. Field of the Invention
This invention relates generally to a processor for controlling a stream of input and/or output (I/O) data between a memory associated with a host computer (main processor) and one or more I/O controllers for peripheral devices in a manner offering some relief to the host computer of the burden of effectuating or supervising I/O. In its particular aspects the present invention relates to a programmable I/O processor interposed functionally among a main processor, a memory and a plurality of I/O controllers which I/O processor receives I/O service request signals from said controllers and handles the servicing thereof. The present invention also relates to a data processing system utilizing such I/O processor.
2. Description of the Prior Art
In the prior art, as represented by computer systems ranging from early mainframe computers to current microprocessor systems, each input or output device's controller logic typically presents an interrupt request signal to the main processor, to indicate events including the need to transfer data between memory and the device. In response to the assertion of this signal, the processor suspends the task in which it had been engaged, stores sufficient information in memory so that the task can be resumed in the future, and begins executing a subprogram which identifies the source of the interrupt request and then transfers any necessary data. When these things are accomplished, the main processor then fetches the previously stored information and resumes the task it had been performing.
This interrupt-driven means of accomplishing input/output has long been recognized to have a number of disadvantages. First, it may require numerous memory cycles to store the information about the main processor's former task and state (the exact number is dependent on the particular processor being used).
Second, in many systems a single interrupt request line, or a small number of such lines, carries all the event notifications from multiple I/O controllers and devices to the processor. Therefore the processor, by some combination of hardware and software means, must next identify which of the various devices has caused the interrupt, and if several devices are signalling an event, which of them should be processed first. When this is accomplished the processor begins executing a subprogram that is specific to the selected device, or a subprogram that is common to all devices of the same type as the selected device.
Third, the operation of most input and output devices can give rise to situations and events other than normal data transfer. For example, a tape drive can come to the end of its recordable medium, or a communications controller may detect a parity-check error in received data. Therefore, the subprogram must next check whether any such abnormal event has occurred before it can perform the data transfer. Typically this is done by reading a status register in the selected input/output controller, and interpreting the resulting value. Further, the interpretation of certain bits or flags within a status value many depend on the state of other bits/flags, and/or certain bits/flags may have "priority" over others as to the order in which they should be checked. Such characteristics lead to "tree structured" decision-making logic within the subprogram, wherein a series of successive examinations of the status is required. This further extends the execution time of the subprogram.
Only when the status has been examined and found to indicate a normal data-transfer request can the subprogram actually transfer the data between the controller and memory. At this point the subprogram may also send one or more commands to the controller to condition its future operation. For example, when the last of the data to be written in a record on a tape drive has been transferred, the drive may have to be commanded to stop tape motion. Also, at some point in this process and by some combination of hardware and software means, the controller must be conditioned to stop asserting its interrupt request signal for the current event, so that the processor will not be interrupted again for this same event.
Last, the processors must retrieve the information about its former activity, so that is can resume the activity, which may again require numerous memory accesses.
The main drawback of interrupt-driven input/output, then, is the time required to perform all of the functions described above, using a general-purpose instruction set like that found on common processors. Out of the total time the processor requires to perform these steps, only a small fraction is typically devoted to the actual data transfer between the controller and memory. If there are many input/output devices, and/or some or all of the devices have high data transfer rates, a large percentage of the main processor's time may be devoted to such I/O interrupts, to the detriment of system performance for computation and/or higher level aspects of system control. In worst-case situations with respect to the arrival of events, input data may even be lost, or output data may be distorted, because the processor can not respond to all the events in a timely manner.
The impact of interrupt-driven input/output on microprocessor operation can be illustrated utilizing a typical, but efficient, interrupt handling subprogram on a 68010 microprocessor (manufactured by Motorola and Signetics) to service interrupt requests from a Signetics 2698 Octal Universal Asynchronous Receiver/Transmitter (OCTART), an eight-channel full-duplex communications controller. The performance of the sub-program is enhanced by the fact that the 68010 needs only four memory transfers to save (restore) its prior task state. Second, it features vectored interrupts, which minimize the time needed to identify which device is interrupting. Third, its stored task state includes the vector number of the interrupting device, which eliminates the need for unique subprogram entry points for each OCTART, each of which would provide instructions to save registers and load a register with the identity (address) of the interrupting OCTART before proceeding to a common routine.
Despite these architectural advantages and despite being efficiently coded in 68010 machine/assembly language, it can be shown that handling one 2698 device that is operating full duplex at 9600 bits/second (a common communications rate) can require 70% of the processing capability of the 68010 just to receive and transmit characters, without processing them in any way. This figure includes the further assumption that the processor is able to use its system bus at 100% utilization. Such a figure indicates to those skilled in the art, that if other devices share use of the system bus with the 68010, and/or if the same processor must also process the data being received and transmitted in any way, the 68010 is probably insufficient to the task of handling one such I/O controller
A common solution to such performance problems, in applications like multi-user UNIX (a trademark of AT&T Bell Laboratories) systems, is to include multiple processors in the system. Typically each processor but one is dedicated to the task of handling the input/output for whatever number of I/O devices its performance will allow (for the above example the number might be four communication lines). This solution increases system size and cost and drastically increases software (operating system) complexity.
For high-speed devices, problems with interrupt-driven input/output have led to the development of specialized hardware, ranging from "selector channels" on mainframe computers to "DMA controllers" in microprocessor systems, that can transfer data at high speed between a device controller and memory, independently of the main processor. Such facilities, in turn, have a number of limitations.
First, in general they are well-adapted to systems handling a small number of high-speed devices, but are not optimal for handling a large number of slower devices. Some devices of this type (selector channels) may restrict operation so that only one among the attached devices may operate at a time.
Second, such devices typically require their attached controllers to provide a specialized signaling interface that is different from that needed for interrupt-driven I/O. Compounding this problem, the various designers and manufacturers of such devices and controller devices have never standardized this interface. A difference in the interface between an I/O controller and a device of this type may require additional "glue" logic between the two, or may well make it impossible to interface a particular device of this type to a particular I/O controller.
Third, such devices typically have a very limited ability to handle events and conditions other than a straightforward data transfer request, and a very limited ability to track the context and status of attached controllers and respond differently based on said context.
On the other hand, as disclosed in U.S. Pat. No. 4,591,973, an I/O processor can be constructed using a general purpose microprocessor to control output data processing and distribution, input data collection and processing, Input/Output testing and system monitoring. By using a general purpose microprocessor, it is possible to program it to handle events dependent upon the status and context of the attached controllers. However, the time required for the execution of the necessary instructions, using such a general purpose microcomputer, severely limits the amount, or number of channels, of I/O that can be handled.